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A METHOD AND APPARATUS RELATING TO TRANSMISSION OF 
DATA 



Field of the invention 

The present invention relates to data transmission in general, and more particularly to a 
5 method and apparatus for improving the procedures for error detection and recovery in data 
communication systems. 

Background 

Most data communication systems consist of a number of nodes, between which data is 
transmitted by use of several protocols. The protocols used within a node is often referred 

10 to as a protocol stack, the lower layer protocols in the protocol stack being closer to the 
physical interface used for the transmission of data to/from the node, while higher layer 
protocols are close to the application used by a user of the data communication system. The 
protocols used within different nodes need by no means be the same. Each protocol in a 
protocol stack has a corresponding protocol in another protocol stack in at least one other 

1 5 node, with which the protocol in the stack communicates. The highest layer protocol used 
within the system is often referred to as the application layer protocol. The lower layer 
protocols used within the data transmission system enable the application layer protocol in 
one node to communicate with the application layer protocol in other nodes. 

20 For some transmission types, such as the transmission of speech, it is more important that 
data arrives on time than that the received data is an exact copy of what was originally 
. transmitted. For other transmission types, such as the downloading of information from the 

: Internet, h is important that the received data is identical to the data originally transmitted, 

. • . : and this criterion is given higher priority than that the data arrives at the receiver within a 

25 certain period of time. In many data communication systems, a possibility of re-transmitting 
• : - data, which for some reason was not correctly received, is therefore included. Such 

functionality for re-transmission of data can be implemented at several protocols used 
within a protocol stack. 




2 



Summary 

A problem to which one aspect of the present invention relates is how to make the 
communication of data in a data communication system more efficient. 



5 This problem is addressed by a method in a data communication system wherein data is 
* transmitted by use of at least two protocols that are capable of re-transmission of data. Each 

of said protocols are implemented in at least two nodes of said data communication system, 
the implementation of a protocol implemented in a transmitting node being a transmitting 
protocol entity and the implementation of a protocol in a receiving protocol being a 

10 receiving protocol entity. One of said at least two protocols capable of re-transmission of 
data is a higher layer protocol than another of said at least two protocols, said another 
protocol therefore being a lower layer protocol. The higher layer transmitting protocol 
entity provides the lower layer transmitting protocol entity with a protocol data unit to be 
transmitted. The method is characterised by the higher layer transmitting protocol entity 

1 S awaiting a transmission result from said lower layer transmitting protocol entity, said 

transmission result reporting the result of the transmission of said protocol data unit by said 
lower layer transmitting protocol entity, the higher layer transmitting protocol entity 
receiving said transmission result, and deciding, responsive to said transmission result, 
whether the higher layer transmission protocol entity should re-provide said lower layer 

20 transmitting entity with said protocol data unit for transmission. 



The problem is further addressed by a computer program comprising software code 
portions for, when said software code portion is run on a computer serving as a transmitting 
node in a data communications system, providing another computer program with a 

• * 25 protocol data unit to be transmitted within said data communication system. The computer 
1 9 program further comprises software code portions for re-providing said another computer 

• m • 

! i program with the protocol data unit. The computer program is characterised by computer 

• •> ► 

* / code portions for awaiting, from said another computer program, a transmission result 

"]] m reporting the transmission of said protocol data unit and computer program portions for 

30 receiving said transmission result from said another computer program. In one aspect of the 

. - . . : invention, said computer program further comprises computer code portions for deciding 

:* whether or not to re-provide said protocol data unit to said another computer program, the 



computer code portions for deciding being adapted to use said transmission result in 
deciding whether or not to re-provide said protocol data unit 

By said method and computer program is achieved that the risk is eliminated that the same 
user data is successfully transmitted between nodes more than once. Hence, the 
transmission resources will be used in a more efficient way, resulting in that more data 
transmission session can be served, and that the transmission times for each data 
transmission session will be shortened. The risk of a protocol, such that the Transmission 
Control Protocol (TCP), decides that a data session is not functioning properly and should 
be closed due to long transmission times is reduced. 

The problem is further addressed by a method in which the lower layer transmitting 
protocol entity sends a transmission result to the higher layer transmitting protocol entity, 
said transmission result reporting the result of transmission of the protocol data unit by the 
lower layer transmitting protocol entity. Hereby is achieved that the higher layer 
transmitting protocol entity receives information based upon which the decision of whether 
or not the protocol data unit should be re-provided is taken. 

In one aspect of the invention, said protocol data unit is identified in the communication 
between the higher layer transmitting protocol entity and the lower layer transmitting 
protocol entity, by use of an identifier. Hereby is achieved that several protocol data units 
can be transmitted directly following each other. Said identifier could e.g. be an identifier 
local to the communication between the higher layer transmitting protocol entity and the 
lower layer transmitting protocol entity. By using a local identifier is achieved that the 
identifier can take large values. Furthermore, the lower layer transmitting protocol entity 
will not need to open the protocol data unit provided by the higher layer transmitting 
protocol entity. In one embodiment, said identifier is assigned to said protocol data unit by 
said higher transmitting protocol entity. Hereby is achieved that the communication of said 
identifier can be performed in the message in which the protocol data unit is provided to the 
lower layer transmitting protocol entity. In anther embodiment, said identifier is assigned to 
said protocol data unit by the lower layer transmitting protocol entity. 
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In one embodiment of the invention, said higher layer transmitting protocol entity receives 
an acknowledgement of reception of said protocol data unit from said lower layer 
transmitting protocol entity after having provided said lower layer transmitting protocol 
entity by said protocol data unit, said protocol data unit being identified by said identifier in 
5 said acknowledgement of reception. 

In one aspect of the invention, said transmission result is transmitted to said higher layer 
transmitting protocol entity from said lower layer transmitting protocol entity in a message 
which is transparently relayed by some or all of any intermediate protocol entities. 

10 

The invention is advantageously applicable to data communication systems comprising a 
radio interface. One aspect of the invention is applicable to data communication systems 
wherein said radio interface is a radio interface in a mobile radio communication system. In 
situations where said mobile radio communication system is a mobile radio communication 
1 5 system operating according to the General Packet Radio System standard, said higher layer 
transmitting protocol entity could be a Logical Link Control protocol and said lower layer 
transmitting protocol entity could be a Radio link Control/Media Access Control protocol. 

Brief description of the drawings 

Fig. 1 is an overview of a data communication system. 

Fig. 2 is an example of protocol stacks used for communication of data within a data 
communication system including a mobile radio network operating according to the GPRS 
standard. 

Fig. 3 gives a schematic example of how user data is encapsulated by protocols used for 
transmission in the data communication system. 

Fig. 4a is an example of an inventive signalling diagram used for signalling between a higher 
layer protocol and a lower layer protocol, both protocols being capable of re-transmission 
of data, when both protocols are implemented in the same node. 




Fig. 4b is an example of an inventive signalling diagram used for signalling between a higher 
layer protocol and a lower layer protocol, both protocols being capable of re-transmission 
of data, when the two protocols are implemented in different nodes. 

Fig. 5a is an example of a message used for transmitting a Protocol Data Unit (PDU) from a 
higher layer protocol to a lower layer protocol. 

Fig. 5b is an example of a message used for acknowledging the reception of a PDU by a 
lower layer protocol to a higher layer protocol. 

Fig. 5c is an example of a message used for reporting the result of the transmission of a 
PDU by a lower layer protocol to a higher layer protocol. 

Fig. 6 schematically illustrates one embodiment of the invention in a flow chart. 

Fig. 7 is an example of protocol stacks used for communication of data within a data 
communication system including a mobile radio network operating according to the 
Universal Mobile Telephony System (UMTS) standard. 

Detailed description 

A data communication system 100 including radio interface 105 is illustrated in Fig. 1 . The 
data communication system 100 will hereinafter be referred to as the system 100. The 
system 100 shown in Fig, 1 is, for the purposes of illustration, shown to include a mobile 
radio network 110 operating according to the General Packet Radio Services (GPRS) 
standard. However, the invention is advantageously applicable also to systems 100 including 
other radio interfaces, such as radio interfaces operating according to the Universal Mobile 
Telephony System (UMTS) standard or the Wireless Local Area Network (W-LAN) 
standard, or to any other system 100 in which several protocols are individually capable of 
re-transmission of data. 

The mobile radio network 110 comprises a Base Station Subsystem (BSS) 1 15, a Serving 
GPRS Support Node (SGSN) 120, and a Gateway GPRS Support node (GGSN) 125. A 



Mobile Station (MS) 130 can communicate within the system 100 via the radio interface 
105. On the other side of the radio interface 105, the BSS 1 15 is connected to the SGSN 
120 via an interface 135 referred to as the Gb-interface 135, The SGSN 120 is further 
connected to the GGSN 125, which in turn is connected to other networks 140 such as the 
Internet, Public Switched Telephony Networks (PSTNs), Integrated Services Digital 
Networks (ISDNs) or other mobile radio networks. 

In Fig. 2, an example of protocol stacks that can be used for the transmission of data in 
system 100 of Fig. 1 are illustrated. For illustrative purposes, the protocol stacks shown are 
not complete, but some protocols, such as higher layer protocols in the SGSN 120 protocol 
stack and the physical layer protocols, are left out. Hereinafter, when referring to a certain 
protocol in general, a reference numeral such as e.g. reference numeral 200 will be used, 
while the same reference numeral, with a letter appended, will be used for referring to the 
protocol when implemented on a specific node. Hence, protocol 200A, 200B, 200C etc, 
will all be implementations of the protocol 200, on different nodes. By a protocol which is 
implemented on a node should be understood a computer program, executable on a 
processor on said node, in accordance with the functionality of the protocol. However, in 
order to simplify the description, the term protocol is used both to denote the set of 
instructions for transmission known as a protocol, and to denote the executable computer 
program implemented on a node for the execution of said instructions. In the following, a 
protocol in a protocol stack of a transmitting node will be referred to as the transmitting 
entity of the protocol, while the corresponding protocol to which the protocol in the 
transmitting node transmits data will be referred to as the receiving entity of the protocol. 
Obviously, in two way communication, a protocol in a certain protocol stack will alternately 
be the receiving entity of the protocol and the transmitting entity of the protocol. 

The example of a protocol stack for use in the MS 130 shown in Fig. 2 comprises the 
following protocols: An application layer 200A, Transmission Control Protocol (TCP) 
202A, Internet Protocol (IP) 20SA, SubNetwork Dependent Convergence Protocol 
(SNDCP) 210A, Logical Link Control (LLC) 21 5 A, Radio Link Control/Media Access 
Control (RLC/MAC) 220A. The protocol stack used in BSS 1 15 for communication via 
radio interface 105 comprises the RLOMAC 220B, which is a protocol corresponding to 
RLC/MAC 220A, and a relay layer 225, while the protocol stack of BSS 115 used for 



transmission via the Gb-inlerface 135 comprises the protocols Base Station System GPRS 
control (BSSGP) 230A and network 235A (network 235 is used in the figure to represent 
the use of either Frame Relay or TCP/DP, as specified in the GPRS Technical Specification 
(TS) 48.016). In SGSN 120, the following protocols are shown (starting with the lower 
layers protocols): network 235B, BSSGP 230B, LLC 215B and SNDCP 210B. The 
corresponding protocols of TCP 202A and IP 205A, i.e. TCP 200B and IP 205B, are 
implemented in further nodes, not shown in Fig. 2. When MS 130 is sending data, the 
RLC/MAC 220A is the transmitting entity of the RLC/MAC protocol 220 while RLC/MAC 
220B is the receiving entity of the RLC/MAC protocol 220, and vice versa. When 
RLC/MAC 220A is the transmitting entity of the RLC/MAC protocol 220, then the LLC 
21 5A is the transmitting entity of the LLC protocol 215, and so forth. 

With reference to Fig. 2, a schematic example 130 is shown in Fig. 3 of how user data 300, 
to be transmitted by MS 130, is encapsulated by the protocols used for transmission in 
system 100, the protocols in the protocol stack of MS 130 being used in the example for 
purposes of illustration. Note, however, that the protocols used for encapsulation of user 
data 300 need not be located within the same node, but can be located in different nodes 
involved in the transmission. Each protocol of the protocol stack adds information to the 
data by adding a header, and possibly a trailer, to the data received from the protocol layer 
above, as is shown in Fig. 3. In Fig. 3, in order to simplify the description, only the addition 
by each protocol of a header layer is shown, and no addition of a trailer. In the application 
layer 200, an application layer header 305 is added to the user data 300, to form the 
application data 3 10, which makes up an application layer Protocol Data Unit (PDU) 315. 
In TCP 202 A, a TCP header 320 is added to the application layer PDU 315, m order to 
make up a TCP PDU 325. Similarly, when receiving the TCP PDU 325 from the TCP 
202A, IP 205A adds an IP header 330 to the TCP PDU 325 in order to form an IP PDU 
335. In SNDCP 210A, an SNDCP header 340 is added to the IP PDU 335 in order to form 
an SNDCP PDU 345, and in LLC 215A, an LLC header 350 is added to the SNDCP PDU 
345 in order to form a LLC PDU 355. Similarly, RLC/MAC 220A adds an RLC/MAC 
header 360 to the LLC PDU 355 in order to form an RLC/MAC PDU 365, Hence, the 
same user data 300 is included in all the PDUs 315, 325, 335, 345, 355 and 365 of Fig. 3. 
In order to simplify the description, each PDU of Fig. 3 is shown to correspond to one PDU 
of each other protocol. However, a protocol data unit of a higher layer protocol may very 
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will be divided into smaller segments by the sending entity of a lower layer protocol, so that 
a PDU of a higher layer protocol corresponds to several PDUs of a lower layer protocol 

At least four of the protocols shown in Fig. 2 have the capability of error detection and 
recovery, so that a Protocol Data Unit (PDU) is re-transmitted, should the originally 
transmitted PDU for some reason appear to not have reached the receiving protocol entity. 
The capability of re-transmitting data within a protocol is indicated by double-pointed 
arrows 237 in Fig. 2. Re-transmission of data can be executed between the MS 130 and the 
BSS 1 15 by the RLC/MAC protocol 220, between the MS 130 and the SGSN 120 by the 
LLC protocol 215 and end-to-end by the TCP protocol 200 or the application layer 200. 

The re-transmission of data can be initiated by the receiving entity of a protocol, realising 
that received data is faulty or that expected data is missing, or by the transmitting entity of a 
protocol not having received an expected acknowledgement of receipt from the receiving 
entity of said protocol. Since re-transmission can be initiated by different protocols in a 
system 100, there is a risk that the same user data 300 is successfully transmitted between 
communicating nodes more than once. To successfully transmit the same user data 300 
more than once is disadvantageous in many ways. The (often scarce) transmission resources 
are used in a non-optimal way. One consequence of this is that fewer data transmission 
sessions can be served. Furthermore, the time used for completing a data transmission 
session will be unnecessarily long, since several PDUs will be re-transmitted even after the 
success&l reception of an identical PDU. In some instances, data transmission times may be 
prolonged to such an extent that a protocol, such as e.g. the TCP protocol 202, decides that 
the rate of data transmission should be reduced, or even that the data transmission session is 
not functioning properly and that it therefore should be closed. Such situations will naturally 
be very frustrating to the user of system 100. 

In a system 100 including a mobile radio network 1 10 operating according to the GRPS 
standard, used as an example in Fig. 1 and Fig. 2, a timer can be associated with each PDU 
transferred by a protocol capable of re-transmitting (see GPRS TS 44.064 for the LLC 
protocol, GPRS TS 44.060 for the RLC/MAC protocol). A protocol will not re-transmit a 
certain PDU until the timer associated with the PDU has expired. The expiry times of the 
timer used by a certain protocol can then differ from the expiry times of the timer used by 



other protocols. Such timers can advantageously be set so that the timer associated with the 
lowest layer protocol expires after the shortest period of time, and a timer associated with a 
higher layer protocol expires after a longer period of time. In some cases, this will be a 
success&l way of avoiding re-transmission of the same data by more than one protocol at a 
time. However, for reasons such as, for example, that the quality of the radio interface 
varies substantially over time, it can be very difficult to estimate the optimal timer expiry 
times. 

In cases where the receiving entities of the different protocols, capable of error detection 
and recovery, all detect error of transmission, or when the timers of the higher layer 
protocols expire before the lower layer protocols have finished their re-transmission, several 
protocols could simultaneously be re-transmitting the same user data 300 towards the same 
interface. Referring now to Fig 3 as an example* application data 310, including user data 
300, could e.g. be re-transmitted a number of times by KLC/MAC 220, a number of times 
by LLC 215, and a number of times by TCP 202. If the transmitting entity of KLC/MAC 
220 is successful in transmitting an RLC/MAC PDU 365, including application data 310, 
the transmitting entity of LLC 215 might in the meantime have provided the transmitting 
entity of RLC/MAC 220 with additional copies of LLC PDU 355, including application data 
3 10, for re-transmission. These additional copies could either have originated from the re- 
transmission functionality in the application layer 200, from the re-transmission functionality 
of TCP 202, from the re-transmission functionality in LLC 215 itself or from a combination 
of these. The transmitting entity of RLC/MAC 220 will not recognise that the data included 
in these additional copies of LLC PDU 355 has already been successfully transmitted, and 
will re-transmit the additional copies of LLC PDU 355. Often, there is an upper limit to 
how many times a PDU should be re-transmitted by each protocol, but a scenario where a 
certain PDU is unnecessarily re-transmitted a large number of times can easily be fbreseea 
The effect of unnecessary re-transmission is, inter alia, that scarce transmission resources 
are being misused, that the time needed to complete a data transmission session will be 
unnecessarily long, and that in some instances, the data transmission session will be closed 
due to long transmission times. 

In order to avoid unnecessary re-transmission of data, different protocols capable of error 
detection and recovery could be made to co-operate with each other. A higher layer 
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protocol could e.g. be made to wait for a report regarding the result of the (re-)transmission 
of a certain PDU performed by lower layer protocols, before any decision is taken about 
whether the higher layer protocol should perform any re-transmission of said PDU. In Fig. 
4, an example of such co-operation between different protocols is illustrated in signalling 
5 diagrams, where co-operation between the LLC protocol 215 and the RLC/MAC protocol 
220 in transmitting data to/from MS 130 is given as an example. The discussion below will 
be held in terms of these two protocols. However, co-operation between other protocols 
capable of re-transmission of data could be implemented in a similar maimer. It should be 
noted that Fig. 4a represents a situation where the lower layer and the higher layer re- 
10 transmission capable transmission protocol entities are located in the same node, while Fig. 
4b illustrates the situation where the lower layer and the higher layer re-transmission 
capable transmission protocol entities are located in different nodes (cf. Fig. 2). 

In Fig. 4a, an example of the provision of protocol data units from LLC 215A in MS 130 to 
15 RLC/MAC 220B in BSS 115 is illustrated in a signalling diagram, in which flow of timeis 
indicated by arrow 400. LLC protocol 2 ISA sends a message 401, including an LLC PDU 
355, to the RLC/MAC protocol 220A in MS 130, the LLC PDU 355 being formatted 
according to the GPRS TS 04.64, hereby included by reference. The LLC PDU 355 is 
indexed "N" for identification within the mobile radio network 110. RLC/MAC 220A then 
20 confirms the receipt of message 401 in an identification message 405, containing an 

identifier I, assigned to LLC PDU(N) 355 by RLC/MAC 220A and used for identification 
of LLC PDU(N) 355 in the communication between LLC 215A and RLC/MAC 220A. 
Furthermore, RLC/MAC 220A transmits the data included in LLC PDU(N) 355 to the 
RLC/MAC 220B in BSS 115, see message 410, in an RLC/MAC PDU 365 in message 410. 
25 In the example given in Fig. 4a, RLC/MAC 220B inBSS 115 does not acknowledge the 
: receipt of message 410, and RLC/MAC 220A re-transmits the RLC/MAC PDU 365 in 

; messages 410A, 410B, 410C and 410D. When having performed the re-transmission of 

" ; * RLC/MAC PDU 3 65 a number of times, corresponding to a pre-set maximum number of 

""I times for re-transmission (i.e. four times in the example given), RLC/MAC 220 A reports, in 

*::: 30 message415,toIXC215Athe^ureoftramniUsionofmeLLCPDU355identifiedby 
„ j"- the identifier L LLC 215A then re-transmits the LLC PDU(N) 355 to RLC/MAC 220A in a 

,-\ message 420, identical to message 401. Alternatively, LLC 215A could issue an alert, 

indicating that an error has occurred, and/or provide RLC/MAC 220A with a different LLC 
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PDU 355 to be transmitted. As seen in the signalling diagram of Fig. 4a, LLC 215A does 
not perform any re-transmission of LLC PDU(N) 355 until LLC 215A has received, in 
message 415, a negative report regarding the transmission of said LLC PDU(N) 355 from 
RLC/MAC 220A. 

5 

In Fig. 4b, an example of a signalling diagram representing the provision of protocol data 
units from the LLC 215B in SGSN 120 to the RLC/MAC 220A in MS 130, in which the 
arrow 400 indicates the flow of time. An LLC PDU(N) 355 is transmitted, in message 425, 
from LLC 21 5B towards RLC/MAC 220B via BSSGP 230B in SGSN 120. The LLC 

1 0 PDU(N) 3 55 is indexed "N" for identification purposes within the mobile radio network 
1 10. Message 425 can then be transparently transmitted from BSSGP 230B to BSSGP 
230A inBSS 115 via Network 235B in SGSN 120 and Network 235AinBSS 115, and 
from BSSGP 230B to RLC/MAC 220B in BSS 115, see messages 425mv. Upon reception 
of message 425/v, RLC/MAC 220B confirms the receipt of message 425 in an identification 

1 5 message 430 sent towards the LLC 21 5B, the identifier message 430 containing an identifier 
I, used for identification of LLC PDU(N) 355 in the communication between LLC 215 and 
RLC/MAC 220. The message 430 can then be transparently transmitted from RLC/MAC 
220B in BSS 1 15, to LLC 215B in SGSN 120 via BSSGP 230A and Network 235A in BSS 
1 15, and Network 235B and BSSGP 230B in SGSN 120. The exchange of message 430 

20 can be distinguished from the exchange of message 425 by the use of a parameter Type of 
Primitive (TOP) included in the message. 



When RLC/MAC 220B has received message 425/v, RLC/MAC 220B furthermore 
transmits, in message 435, the data included in LLC PDU(N) 355 received in message 425/v 
25 to RLC/MAC 220A in MS 130, Le over radio interface 105, in an RLC/MAC PDU 365. In 
: the example given, the transmission of RLC/MAC PDU 365 was successful at the first 

attempt, and an acknowledgement of the receipt of RLC/MAC PDU 365 is transmitted 
' * ] : from RLC/MAC 220A to RLC/MAC 220B (see message 440). Upon reception of the 

acknowledgement message 440, the RLC/MAC 220B in BSS 1 15 then reports, to the LLC 
30 21 5B in SGSN 120, the success of the transmission of the protocol data unit identified by 

identifier I (see message 445). Message 445 could be transparently transferred to LLC 215B 
: in a similar manner to the transparent transmission of message 430 (see messages 44S/-/v). 

LLC 21 SB in SGSN 120, which has not sent any further protocol data units towards 
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RLC/MAC 220B since sending message 425, can upon the reception of message 445/v send 
another protocol data unit to RLC/MAC 220B, e.g. LLC PDU(N+1) 355 (see message 
450). The messages 425, 430 and 445 will be further discussed in relation to Figs. 5a, 5b, 
5c. 

In fig 4a and 4b, for illustrative purposes only, the messages 410 and 435 have been shown 
to carry the same amount of user data 300 as the messages 401 and 425, respectively, Le. 9 a 
message 401/425 corresponds to one message 410/435. However, in most implementations, 
the transmitting entity of RLC/MAC 220 would divide an LLC PDU 355 into smaller 
segments, each segment being transmitted in a separate message 410/435. Thus, each 
message 401/425 would correspond to several messages 410/435, see e.g. GPRS TS 
44.060, hereby incorporated by reference. In order to report a successful transmission of a 
certain LLC PDU(N) 355 across the radio interface 105, RLC/MAC 220 would have 
received acknowledgement from the receiving node that all RLC/MAC PDU 365 messages 
410/435 corresponding to the LLC PDU(N) 355 carried in message 401 have been 
successfully received. 

In Fig. 4a, the re-transmission of an LLC PDU 355 by LLC 215A was initiated when no 
response was received by RLC/MAC 220A from RLC/MAC 220B, even after RLC/MAC 
220A having re-transmitted message 410 several times. In other situations, the re- 
transmission of an LLC PDU 355 could be triggered by a negative acknowledgement 
received by the transmitting entity of RLC/MAC 220 from the receiving entity of 
RLC/MAC 220 - the receiving entity informing the transmitting entity that it has not 
successfiiUy received the transmitted message 410. When the transmitting entity of 
RLC/MAC 220 receives a positive acknowledgement from the receiving entity of 
RLC/MAC 220, obviously, no re-transmission of the LLC PDU 355 by the transmitting 
entity of LLC 215 is needed. This case is illustrated in Fig. 4b. 

The signalling diagrams presented in Figs 4a and 4b can be varied in many ways. The 
message 405/430 of Fig. 4 could e.g. be omitted, and instead, the transmitting entity of LLC 
215 could assign an identifier I to LLC PDU(N) 355, said identifier being included in 
message 401/425. The transmitting entity of RLC/MAC 220 could then send an 
acknowledgement of reception of message 401/425 to the transmitting entity of LLC 215, 
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or alternatively, the transmitting entity of RLC/MAC 200 could send no confirmation of the 
reception of message 401/425 to the transmitting entity of LLC 215, but rather, the 
transmitting entity of LLC 215 could assume that message 401/425 is always safely received 
by the transmitting entity of RLC/MAC 200. 

5 

In another embodiment of the invention, the index TT, used for identification of an LLC 
PDU 355 in the network 1 10, could be used for identification of a certain LLC PDU 355 
also in the communication between transmitting entities of LLC 215 and RLC/MAC 220 
(referred to in this context as local communication) rather than a separate, local, identifier I. 
1 0 Message 405/430 could then be omitted, or could contain an acknowledgement of the 

reception of LLC PDU(N) 355. Message 415/445 could then contain information about the 
success/failure of the transmission of the data contained in LLC PDU 355 indexed M N" over 
the radio interface 105. An advantage of doing so is that only one identifier is used for the 
identification of an LLC PDU 355, resulting in a simpler identification system. However, 
1 5 there are advantages also of using a separate identifier for the local communication between 
the transmitting entities ofLLC 215 and RLC/MAC 220. One such advantage is that the 
identifier I does not, since it is only used locally, need to be transmitted over the radio 
interface 105, and can hence be a large number. The identifier N on the other hand, since it 
is used within mobile radio network 110 and hence is transmitted over the radio interface 
20 which has a limited bandwidth, has, in a system 100 including a GPRS radio interface, a 
typical value of 5 12 bits. A local identifier which does not have to be transmitted over the 
radio interface 105, could take values larger than the maximum value of N. Thus, the risk of 
confusing different protocol data units with each other, or alternatively, the risk of having to 
wait for the confirmation of the successful transmission of a PDU(N) before a different 

: " : 25 PDU, identified by the same number N, can be transmitted, can be reduced. Furthermore, if 
: the identifier N is used as a local identifier in the communication between the transmitting 

'{'[ entities of LLC 215 and RLC/MAC 220, the transmitting entity of RLC/MAC 220 will have 

• / to open the LLC header 360 in order to read the value of identifier N, If a separate identifier 

• • ; I is used as the local identifier, then the transmitting entity of RLC/MAC 220 will not need 
lll m 30 to open the LLC header 360, thus making the transmission process fester. Alternatively, the 

identifier N could be handled separately in the communication between RLC/MAC 220 and 

• • • . LLC 21 5, in a manner similar to the handling of identifier L 
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In Figs. 4a and 4b, the transmitting entity of IXC 215 has been shown not to send any 
further messages 401/425 to the transmitting entity of KLC/MAC 220 after having sent 
message 401/425, until having received message 415/445. However, the transmitting entity 
of LLC 215 may very well transmit LLC PDUs 355 other than the LLC PDU(N) 355 
5 included in message 401/425 to the transmitting entity of RLC/MAC 220 before having 
received message 415/445 from KLC/MAC 220A A certain LLC PDU 355 will, however, 
be transferred only once by LLC 215A before LLC 215A has received the result of 
transmission (message 415/445) regarding said certain LLC PDU 355. The transmission of 
PDU(N+1) etc. from the transmitting entity of LLC 215 could take place either before or 
1 0 after the transmitting entity of LLC 215 has received message 405/430. 

An example of message 401/425 is shown in Fig. 5a, where the message 401/425 contains 
two different fields. A first field 500 is used to indicate the Type of Primitive (TOP) to be 
transmitted in the message. In message 401/425, the field 500 could take the value "LL- 

! 5 Data identifier", and e.g. include the value "N". Field 505, shown in Fig. 5a, is used to 
transmit the LLC PDU 355 to be forwarded by RLC/MAC 220. The digits above the 
respective fields are used to indicate the number of octets therein, and are given as examples 
only. Field 505, could for ©cample contain n octets, of which n-3 could be used for LLC 
PDU 355, one octet could be used to indicate the type of data, and two octets could be 

20 used to indicate the length of LLC PDU 355. 

In Fig. 5b, an example of messages 405/430 is shown, used in an embodiment where an 
identifier I is assigned to each LLC PDU 355 by the transmitting entity of RLC/MAC 220. 
The message 405/430 given as an example in Fig. 5b contains three fields: type of primitive 

25 510, Identifier 1 515 and LLC PDU 520. The field 510 could e.g. take the value U LL-Data 
Identifier I", used to indicate that the message 405/430 contains an identifier I identifying a 
certain LLC PDU 355. Field 515 contains the value of identifier I, which e.g. could consist 
of 4 octets, providing a large range of identifier I values. In order to indicate which LLC 
PDU 355 is identified by the value of field 515, the LLC PDU 355 could be included in 

30 message 405/430 in field 520. Alternatively, only a part of the LLC PDU 355 containing the 
identifier N could be transmitted in field 520. However, in cases where the transmitting LLC 
215 awaits a message 405/430 from the transmitting RLC/MAC 220 before another LLC 
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PDU 355 is transmitted, the field 520 could be omitted LLC 215 could then associate the 
identifier in field 515 of a message 405/430 with the last transmitted LLC PDU 355. 

In Fig. 5c, an example of the messages 415/445 is given. In field 525, the type of primitive 
5 to be transmitted by message 415/445 is indicated, and the value of field 525 could e.g. be 
"Success/Failure for LLC PDU". In field 530, the value of identifier I, used for 
identification of the specific LLC PDU 355 about which information is transmitted, is given. 
Field 535 is used in order to indicate whether the transmission of the LLC PDU 355 
identified by identifier I was successful or not. This field could e.g. comprise one octet, 
1 0 where the value 11111111 could represent success and the value 00000000 could represent 
failure. 

In an embodiment where the identifier I is assigned to a certain LLC PDU 355 by the 
transmitting entity of LLC 215, the contents of messages 401/425, 405/430 and 415/445 
1 5 should be modified accordingly - the identifier I could e.g. be included as a field in message 
401/425. Using the identifier N for identification of a LLC PDU 355 in the communication 
between LLC 215 and RLC/MAC 220 would also give rise to modifications of messages 
401/425, 405/430 and 415/445. 

20 An embodiment of the invention is illustrated in a flow chart in Fig. 6. In step 600, the 

transmitting entity of LLC 215 provides the transmitting entity of RLC/MAC 220 with an 
LLC PDU 355, indexed N, to be transmitted over radio interface 105. In step 605, the 
transmitting entity of RLC/MAC 220 identifies the LLC PDU(N) 355 with identifier I. The 
identifier I can either have been assigned to LLC PDU(N) 355 by the transmitting entity of 

25 LLC 2 1 5 and included in the message containing the IXC PDU(N) 355 sent from the 

transmitting entity of LLC 215 in step 600, or could be assigned to LLC PDU(N) 355 by 
the transmitting entity of RLC/MAC 220 upon reception of the LLC PDU(N) 355. The 
transmitting entity of RLC/MAC 220 then sends an acknowledgement of reception of LLC 
PDU(N) 355 identified by identifier I to the transmitting entity elf LLC 21 5. A counter in 

30 the transmitting entity of RLC/MAC 220 is then set to 1 in step 615. In step 620, the 
transmitting entity of RLC/MAC 220 transmits the data contained in LLC PDU(N) 355 
towards the receiving entity of RLC/MAC 220, located in a node different to the node in 
which the transmitting entity of RLC/MAC 220 is located. This transmission is often 
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performed in a manner so that theLLC PDU(N) 355 is divided into segments, and several 
RLC/MAC PDUs 365, all carrying part of LLC PDU(N) 355, are transmitted towards the 
receiving entity of RLC/MAC 220. However, in order to simplify the description, it is here 
assumed that LLC PDU(N) 355 is transmitted in one RLC/MAC PDU 365. The 
transmitting entity of RLC/MAC 220 then awaits an acknowledgement of reception from 
the receiving entity of RLC/MAC 220 in step 625. If an acknowledgement is received, or if 
a timer in RLC/MAC 220 related to the awaiting of an acknowledgement expires, then step 
630 is entered, in which step it is checked whether the data contained in LLC PDU(N) 355 
has been successfully received by the receiving entity of RLC/MAC 220. If the data of LLC 
PDU(N) 355 has been successfully received, then step 635 is entered, in which step the 
transmitting entity of RLC/MAC 220 informs the transmitting entity of LLC 215 that the 
LLC PDU 3 55 identified by identifier I has been successfully received by the receiving entity 
of RLC/MAC 220. If the result of the check in step 630 is that the data of LLC PDU(N) 
355 has not been successfully received, then step 640 is entered, in which the counter is 
incremented by one. In step 645, it is then checked whether the value of the counter is 
larger than a limit indicating a maximum number of times that an RLC/MAC PDU 365 
should be retransmitted. If so, the transmitting entity of RLC/MAC 220 informs the 
transmitting entity of LLC 215 that the transmission of theLLCPDU 355 identified by 
identifier I has failed. However, if the counter has a value which is lower or equal to the 
limit then step 620 is re-entered. In some embodiments, a timer could be used rather than a 
counter for deternuning how many times a certain RLC/MAC PDU 365 should be re- 
transmitted. 

If the procedure described in Fig. 6 has reached step 635, then the transmitting entity of 
LLC 2 1 5 could advantageously transmit another LLC PDU 3 55 towards the transmitting 
entity of RLC/MAC 220. If the procedure reaches step 650 on the other hand, where 
RLC/MAC 220 informs LLC 215 of the failure of the transmission of LLC PDU(N) 355, 
then step 655 is entered, in which it is decided whether or not to re-transmit the LLC 
PDU(N) 355. If it is decided that LLC PDUW should be re-transmitted, then step 600 is 
re-entered. If it is decided that LLC PDU(N) should not be re-transmitted, then step 660 is 
entered. In step 660, another LLC PDU 3 55 is transmitted, following the flow chart 
described in Fig. 6, and/or an alert is issued indicating that an error has occurred. The 



17 

decision made in step 655 can e.g. be based on how many times the transmitting entity of 
LLC 215 has already re-transmitted LLC PDU(N) 355. 

The procedure described by the flow chart in Fig. 6 is equally applicable to situations where 
the transmitting higher layer protocol and the transmitting lower layer protocol are located 
in the same node (cf Fig. 4a) and where they are located in different nodes (cf. Fig. 4b). 
Furthermore, the flow chart can be altered in many ways. For example, the IXC PDU(N) 
355 could be identified by the index <S N", rather than by the local identifier C T\ In this case, 
as well as in the case when LLC 215 assigns a local identifier W P to the LLC PDU(N) 355, 
step 610 could be omitted. Moreover, the transmission of other LLC PDUs could 
advantageously take place in parallel to the procedure described in Fig. 6, the transmission 
of LLC PDU(N-1), LLC PDU(N), LLC PDU(N+1) etc. occurring sequentially. The 
transmission of LLC PDU(N-1), LLC PDU(N+1) etc would then also follow the procedure 
described in Fig. 6. 

The protocol stacks shown in Fig. 2, used for data transmission in data communication 
systems 100 including a mobile radio system 110 operating according to the GPRS 
standard, are only given as an example of protocol stacks to which the invention can 
advantageously be applied. The invention is equally applicable to data communication 
systems 100 using other protocol stacks in which more than one protocol has the capability 
of re-transmission of data. An example of such a data communication system 100 is a data 
communication system 100 including a mobile radio system 110 operating according to the 
UMTS standard. In Fig. 7, an example of protocol stacks used for the transmission of user 
data 300 between the nodes MS 130, UTRAN (UMTS Terrestrial Radio Access Network) 
1 1 5 (corresponding to BSS 1 15 in Fig. 1), 3G-SGSN 120 and 3G-GGSN 125 of such a 
data communication system are illustrated, where 3G indicates "3"* generation". The 
protocols used within a MS 130 operating according to the UMTS standard could e.g. be, 
as shown in Fig. 7, an application protocol 200A, the TCP protocol 202A, the BP protocol 
205A, the Packet Data Convergence Protocol (PDCP) 710A and RLC/MAC 220A. In 
UTRAN 1 1 5, the protocols RLC/MAC 220B and PDCP 710B are used for communication 
with MS 130, while GPRS Tunnel Protocol-User plane (GTP-U) 715A.and User Datagram 
Protocol/Internet Protocol (UDP/IP) 720A are used for communication with 3G-SGSN 
120. In the 3G-SGSN node 120, the protocols UDP/IP 720B and GTP-U 715B are used for 
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communication of data with UTRAN 1 15, while protocols GTP-U 715C and UDP/EP 720C 
are used for exchange of data with 3G-GGSN 125. In 3G-GGSN 125, the protocols 
UDP/IP 720D, GTP-U 71 5D and IP 205B are used for communication of data with 3G- 
SGSN 120. In the data transmission system illustrated by protocol stacks in Fig. 7, at least 
5 three of the protocols are capable of re-transmitting data: the RLC/MAC protocol 220, 
TCP protocol 202 and the application protocol 200. 

The invention is equally applicable to all data communication which uses more than one 
protocol capable of re-transmitting data. The invention is especially beneficial to data 

1 0 communication involving interfaces where the quality of the transmission and/or the 

available bandwidth varies over time. In such cases, it is difficult to pre-set timers associated 
with re-transmission in an optimal way, since the amount of time needed for successful 
transmission of a certain amount of data varies with time. Examples of systems providing 
data communication exhibiting this behaviour are UMTS, GPRS, W-LAN and other cellular 

1 5 systems and land mobile radio networks. In data communication system such as GPRS and 
UMTS, the bandwidth over radio interface 105 varies over time mainly for two reasons: the 
quality of the radio transmission varies over time due to variations in geographical and 
meteorological conditions, and the bandwidth allocated to a certain data call varies over 
time due to the varying load in the network. Another example of data communication 

20 systems to which the invention could advantageously be applied is data communication 

systems including links which provide different bandwidth in different directions. Although 
the protocols which has been used as an example to illustrate the invention, LLC and 
RLC/MAC, are located in adjacent layers, the invention is equally applicable to protocols 
capable of re-transmission of data that are not located in adjacent layers. 

; " : 25 

: One skilled in the art will appreciate that the present invention is not limited to the 

* * * 

; * • embodiments disclosed in the accompanying drawings and the foregoing detailed 

• ] T description, which are presented for purposes of illustration only, but it can be implemented 
l in a number of different ways, and it is defined by the following claims. 
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Claims 

1 . A method in a data communication system wherein data is transmitted by use of at least 
two protocols that are capable of re-transmission of data, each of said protocols being 
implemented in at least two nodes of said data communication system, the implementation 

5 of a protocol implemented in a transmitting node being a transmitting protocol entity and 
the implementation of a protocol in a receiving protocol being a receiving protocol entity, 
one of said at least two protocols capable of re-transmission of data being a higher layer 
protocol than another of said at least two protocols, said another protocol therefore being a 
lower layer protocol, the higher layer transmitting protocol entity providing the lower layer 

1 0 transmitting protocol entity with a protocol data unit to be transmitted, said method being 
characterised by the following steps: 

awaiting, in the higher layer transmitting protocol entity, a transmission result from 
said lower layer transmitting protocol entity, said transmission result reporting the result of 
the transmission of said protocol data unit by said lower layer transmitting protocol entity; 

1 5 receiving, in said higher layer transmitting protocol entity, said transmission result; 

and 

deciding, responsive to said transmission result, whether the higher layer 
transmission protocol entity should re-provide said lower layer transmitting protocol entity 
with said protocol data unit. 

20 

2. The method of claim 1, wherein 

said protocol data unit is identified, by the higher layer transmitting protocol entity 
in communication with the lower layer transmitting protocol entity, by use of an identifier. 

25 3 . The method of claim 2, wherein 

said identifier is an identifier local to the communication between the higher layer 
transmitting protocol entity and the lower layer transmitting protocol entity. 

4. The method of claim 3, wherein 
3 0 said identifier is assigned to said protocol data unit by said higher transmitting 

protocol entity. 
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5. The method of any of claims 2-4, wherein 

said higher layer transmitting protocol entity receives an acknowledgement of 
reception of said protocol data unit from said lower layer transmitting protocol entity after 
having provided said lower layer transmitting protocol entity by said protocol data unit, said 
5 protocol data unit being identified by said identifier in said acknowledgement of reception. 



6. A method according to claim 1, modified in that said steps of awaiting, receiving and 
deciding are replaced by the following step: 

sending, from the lower layer transmitting protocol entity, a transmission result to 
1 0 the higher layer transmitting protocol entity, said transmission result reporting the result of 
transmission of said protocol data unit by said lower layer transmitting protocol entity. 

7. The method of claim 6, wherein 

said transmission result is transmitted to said higher layer transmitting protocol 
1 5 entity in a message which is transparently relayed by some or all of any intennediate 
protocol entities. 



8. The method of claim 6 or 7, wherein 

said protocol data unit is identified, by the lower transmitting protocol entity in 
20 communication with the higher layer transmitting protocol entity, by use of an identifier. 

9. The method of claim 8, wherein 

said identifier is assigned to the protocol data unit by said lower layer transmitting 
protocol entity. 

/ 10. The method of any of claims 1-9, wherein 

: said higher layer transmitting protocol entity and said lower layer transmitting 

protocol entities are located within different nodes. 



30 11. The method of any of claims 1-10, wherein 

said data communication system comprises a radio interface. 



12. The method of claim 11, wherein 
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said radio interface is a radio interface in a mobile radio communication system. 

13. The method of claim 12, wherein 

said mobile radio communication system is a mobile radio communication system 
operating according to the General Packet Radio System standard; and 

the higher layer transmitting protocol entity is a Logical Link Control protocol and 
the lower layer transmitting protocol entity is a Radio Link Control/Media Access Control 
protocol 

14. A computer program comprising software code portions for, when said software code 
portion is run on a computer serving as a transmitting node in a data communications 
system, providing another computer program with a protocol data unit to be transmitted 
within said data communication system, said computer program further comprising software 
code portions for re-providing said another computer program with said protocol data unit, 
said computer program being characterised by 

computer code portions fbr awaiting, from said another computer program, a 
transmission result reporting the transmission of said protocol data unit; and 

computer program portions for receiving said transmission result from said another 
computer program. 

15. The computer program of claim 14, further comprising 

computer code portions for deciding whether or not to re-provide said protocol data 
unit to said another computer program, said computer code portions for deciding being 
adapted to use said transmission result in deciding whether or not to re-provide said 
protocol data unit 

16. The computer program of claim 14 or 15, further comprising 

computer code portions for allocating an identifier to each protocol data unit, and 
computer code portions for informing said another computer program about said 
identifier. 
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17. The computer program of any of claims 14-16, said computer code portions for 
providing and re-providing being adapted to provide and re-provide according to the 
Logical Link Control protocol. 

1 8. A computer program comprising software code portions for, when said software code 
portion is run on a computer serving as a transmitting node in a data communications 
system, receiving from another computer program a protocol data unit to be transmitted 
within said data communication system and computer code portions for transmitting said 
protocol data unit, said computer program further comprising software code portions for 
re-transmitting said protocol data unit, said computer program being characterised by 

software code portions for sending a message including the result of the 
transmission or re-transmission of said protocol data unit to said another computer 
program. 

19. The computer program of claim 18, farther comprising 

software code portions for allocating an identifier to said protocol data unit, and 
software code portions for informing said another computer program about said 
identifier. 

20. The computer program of claim 18 or 19, said computer code portions for receiving, 
transmitting and re-transmitting being adapted to receive, transmit and re-transmit 
according to the Radio link Control/Media Access Control protocol. 

21. A computer program product comprising a computer readable medium, having stored 
thereon a computer program according to any of claims 14-20. 

22. A node in a data communication system wherein data is communicated, said node being 
characterised by 

a computer program product according to claim 21. 

23. A data communication system wherein data is communicated being characterised by 

a node according to claim 22. 
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Abstract 

The present invention relates to a method and apparatus for improving the procedures for 
error detection and recovery in data communication systems and thereby facilitating a better 
use of data transmission resources. According to the invention, different protocols capable 
of re-transmission of data are made to communicate with each other in order to avoid that 
several protocols simultaneously re-transmit the same data towards the same interface. The 
transmitting entity of a higher layer protocol will, according to the invention, await the 
result of the transmission of a certain protocol data unit by a lower layer protocol before 
making the decision of whether or not the transmitting entity of the higher layer protocol 
should re-transmit the certain protocol data unit 
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